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Fiscal  Year  Spreading 
of  Software  Dollars 


BACKGROUND 

Our  Task  Order  42  team  has  developed  several  funding  profiles 
based  on  a  speciflc  software  development  process,  coupled  with  a  high 
order  development  language.  In  many  cases,  especially  in  Government 
contracts,  the  development  process  and  development  language  are 
specified. 

PURPOSE 

The  purpose  of  this  project  was  to  develop  a  fiscal  year  spreading 
methodology  and  suggested  profiles  for  time-phasing  Strategic  Defense 
Initiative  Office  (SDIO)  software  cost  estimates.  Phasing  effort  by  fiscal 
year  results  in  an  obligation  profile  that  is  suitable  for  use  in  budget 
formulations. 


SCOPE 

This  report  applies  to  the  fiscal  year  phasing  of  software  costs 
associated  with  SDIO  projects.  Obligation  profiles,  presented  in  this  report, 
apply  to  all  SDIO  systems  regardless  of  development  language  or  system 
complexity.  The  profiles  are  based  on  a  software  system  meeting  full  DoD- 
STD-2167A  documentation  requirements.  This  report  considered  only  the 
fiscal  year  spreading  of  the  Software  Development  Phase  of  the  System 
Life  Cycle.  Figure  1  compares  the  Software  Development  Phase  to  the  total 
System  Life  Cycle.  The  purpose  of  this  figure  is  to  orient  the  reader  with 
the  relationship  between  the  Software  Development  Phase  and  the  total 
System  Life  Cycle. 


Figure  1.  System  Life  Cycled* 2 
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*Ada  Parametric  Sizing,  Costing  and  Scheduling,  William  G.  Cheadle,  Martin 
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Marietta  Denver  Aerospace  Corporation,  PO  Box  179,  Denver,  CO  80201 
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The  Software  Development  Phase  begins  during  the  Demonstration 
and  Validation  Phase  (DEMVAL)  and  is  typically  completed  when  the 
Engineering  and  Manufacturing  Development  Phase  (EMD)  ends.  During 
system  production,  the  completed  software  is  placed  under  rigorous 
configuration  control  and  any  changes  are  handled  in  the  same  manner  as 
fielded  software  with  managed  releases  and  centralized  implementation 
control.  The  funding  category  for  the  completed  software  depends  on  the 
life  cycle  phase  of  the  overall  system  (i.e.  Research  &  Development  (R&D), 
Production,  or  Operations  and  Support  (O&S)).  For  example,  during  system 
production,  the  completed  baseline  software  system  configuration  is 
maintained  with  production  money.  After  Helding,  software  is  maintained 
with  O&S  funding. 

In  Figure  2,  the  Software  Development  Phase  is  further  decomposed 
to  show  sub-phases  and  major  design  reviews.  The  profiles  in  this  report 
include  the  costs  of  the  development  phase,  including  all  reviews  and 
documentation  requirements  through  hardware/software  integration 
shown  in  Figure  2.  Production  and  Operations  &  Support  proHles  are  not 
included  within  the  scope  of  this  report. 

Figure  2.  Software  Development  Phase  (DoD-STD-2167A)3>^*^ 
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DoD-STD-2167A,  Defense  System  Software  Development,  which  is  the 
current  development  standard  establishes  uniform  requirements  for 
software  development  that  are  sq>plicabie  throughout  the  system  life  cycle. 
It  provides  the  basis  for  Government  insight  into  a  contractor's  software 
development  and  does  not  specify  or  discourage  the  use  of  any  particular 
software  development  method.  DoD-STD-2167A  provides  the  framework 
for  any  software  development  methodology  (i.e.,  the  products,  processes, 
and  controls),  a  standard  set  of  terminology,  and  a  phase  breakdown.  In 
addition  to  the  phase  breakdown,  DoD-STD-2167A  identifies  required 
milestones,  and  provides  a  Contract  Data  Requirements  List  (CDRL)  with 


^Ada  Parametric  Sizing,  Costing  and  Scheduling,  William  G.  Cheadle,  Martin 

Marietta  Denver  Aerospace  Corporation,  PO  Box  179,  Denver,  CO  80201  (paper 

presented  at  the  1987  ISPA  Conference  held  5-7  May  in  San  Diego,  CA 

^SASET  Training  Course,  William  G.  Cheadle,  16  -  17  December  1992,  Martin 

Marietta  Denver  Aerospace  Corporation,  PO  Box  179,  Denver,  CO  80201 

^DoD  Standard  2167A,  29  February  1988,  Department  of  Defense.  Washington,  DC 
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the  applicable  Data  Item  Descriptions  (DID).  CDRLs  are  required  contract 
deliverables  and  DlDs  provide  instructions  and  report  formats  for  CDRL 
production. 

APPROACH 

The  initial  step  in  this  analysis  was  to  collect  and  review  current 
information  on  software  development  methodologies  and  scheduling 
approaches.  In  addition,  applicable  DoD  and  SDIO  directives  and  standards 
were  reviewed  to  ensure  that  general  requirements  affecting  cost  were 
included  in  this  analysis.  Next,  based  on  the  available  literature,  obligation 
profiles  were  developed  using  nth  degree  regressions.  Finally,  the 
completed  profiles  were  distributed  for  review  by  other  cost  analysts  and 
software  estimators  to  achieve  a  consensus  on  the  reasonableness  of  the 
fiscal  year  percentages  developed  for  this  report. 

ANALYSIS 

Software  development  effort  consists  of  the  participation  of  4 
organizations  (System  Engineering  (SE),  Software  Engineering  (SWE),  Test 
Engineering  (TE),  and  Quality  Assurance  (QA))  to  develop  successful, 
deliverable  software  systems.  Table  1  shows  the  ratio  of  each 
participating  organization  to  the  total  development  effort. 


Table  1.  Software  Development  Organization^ 


Systems  Engineering  -  14  % 

Software  Engineering  -  66  % 

Quality  Engineer  -  5% 

Test  Engineer _  15  % 

Total  Software  Effort  -  100% 


Each  organization  has  a  specific  profile  that  represents  its 
involvement  in  a  given  software  project.  The  spreading  profiles,  which  are 
given  later  in  Table  4,  represent  the  summation  of  the  4  separate 
organization  proHles.  Each  organization  profile  is  based  on  an  nth  Degree 
Least  Squares  Regression  which  generates  an  equation  of  the  form: 

Y  =  a.X-  +a„.,X"-‘  +a„.,X-*...+a,X+ao 


®SASET  Training  Course,  William  G.  Cheadle,  16  -  17  December  1992,  Martin 
Marietta  Denver  Aerospace  Corporation,  PO  Box  179,  Denver,  CO  80201 


3 


FOR  OFFICIAL  USE  ONLY 


The  X’s  and  Y's  are  not  straightforward  to  interpret  and  are  described  in 
further  detail. 


Y  is  used  to  determine  the  percent  of  total  man-effort  for  a 
particular  month.  Once  Y's  are  determined  for  all  months,  each  Y  must  be 
scaled  so  that  their  sum  adds  to  one.  This  is  done  by  dividing  each  Y  by 
the  sum  of  all  the  Y’s.  For  example,  if  Y],  ...,  Y35  corresponds  to  month  1 
through  36  in  a  three  year  profile,  then: 


M 


lY,  £y,  Sy, 

i-t  i-l  l-l 


gives  the  percent  of  man-effort  for  each  month.  Note  that  these  add  up  to 
one. 

X  is  a  measure  of  how  far  a  particular  month  is  through  the  entire 

cycle.  For  example,  month  1  is  —  of  an  entire  36  month  cycle,  month  2  is 

36 

2 

—  of  the  entire  cycle,  etc.  This  would  naturally  give  a  range  of  X  between 

0  and  1.  This  model,  however,  uses  a  range  from  0  to  20  for  X.  Thus, 

month  18  in  a  36  month  profile  would  be  given  a  value  of  10  (10*  ^*20) 

for  X  since  it  is  halfway  through  the  complete  cycle.  In  general,  X  is 
determined  by  taking  the  month  divided  by  the  total  number  of  months  in 
the  cycle  all  multiplied  by  20.  For  example,  the  X  input  for  the  first  month 

1  2 

in  a  three  year  cycle  is  —20,  the  second  month  is  —20,  through  the  last 


36 


36 


36, 


month  which  is  — 20.  As  a  further  example,  the  X  mput  for  the  Hrst  month 
36 

1  2 

in  an  eight  year  (96  month)  profile  is  —20,  the  second  month  is  —20, 

96  96 

96 

through  the  last  month  which  is  — 20.  It  is  unclear  why  a  scaling  factor  of 

96 

20  was  chosen.  One  possibility  is  that  a  range  of  0  to  1  for  X  gave 
exceedingly  high  coefficients  in  the  regression  equations. 


Each  separate  organization  profile  is  based  on  a  different  regression 
equation  from  a  data  base  of  over  600  completed  software  projects.^ 
Martin  Marietta  Denver  Aerospace  calculated  these  least  square 
regressions  using  data  taken  from  the  Space  and  Missile  Systems  Center 

^SASET  User's  Guide,  Version  1.8  and  2.0,  Dr.  Aaron  N.  Silver,  ei.al.,  1990  by 
Martin  Marietta  Denver  Aerospace  Corporation,  PO  Box  179,  Denver,  CO  80201 


4 


FOR  OFFICIAL  USE  ONLY 


Software  Database.  The  coefficients  for  each  organization  are  provided  in 
Table  2. 

Table  2.  Software  Development  -  Manloading  Curve  Coefficients* 


Y 

Intercept 

1st 

Decree 

2od 

Decree 

3rd 

Decree 

4tb 

Degree 

Sth 

Degree 

Systems 

Engineering 

214.41 

-21.03 

1.04 

-0.02 

0.0 

0.0 

Software 

Engineering 

77.72 

-11.18 

6.90 

-0.82 

0.036 

-0.00054 

Test  Engineering 

28.91 

6.35 

-0.34 

0.02 

0.0 

d.o 

Quality 

Assurance 

77.72 

-11.18 

6.90 

-0.82 

0.036 

-0.00054 

As  shown  in  Table  2,  SE  and  T£  profiles  were  based  on  3rd  degree 
regressions,  and  SWE  and  QA  were  based  on  5th  degree  regressions.  Table 
3,  expresses  these  regressions  in  equation  form. 


Table  3.  Software  Development  -  Manloading  Curve  Equations^ 


Systems  Engineering 
Software  Engineering 
Test  Engineering 
Quality  Assurance 


Y  =  214.41-  21. 03X  +  1.04X*-.02X’ 

Y*  77.72 -11.18X  +  6.90X*..82X*+.036X^-.00054X’ 

Y  =  28.41  +  6.35X-.34X*+.02X* 

Y=!  77.72 -11.18X  +  6.90X*-.82X*+.036X‘-.00054X* 


Figure  4  represents  the  Manloading  curves  in  a  three  year  spreading 
profile  for  each  organization  and  the  total  effort,  based  on  the  equations  in 
Table  3.  As  stated  above,  SE  and  TE  profiles  are  based  on  3rd  degree 
polynomials  which  resemble  steadily  decreasing  and  increasing  curves 
respectively.  SWE  and  QA  profiles  are  based  on  5th  degree  polynomials 
which  resemble  bell  shaped  curves.  After  completion  of  the  organization 
curves,  the  four  resulting  profiles  are  summed  to  produce  the  total  profile 
presented  in  Table  4. 


*DBMS  Model,  Dr.  Aaron  N.  Silver,  et.al.,  1990  by  Martin  Marietta  Denver  Aerospace 
Corporation,  PO  Box  179,  Denver,  CO  80201 
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Figure  4.  Total  Manloading  by  Organization 


1  6  11  16  21  2S  31  36 


Calendar  Month* 

RESULTS 

This  analysis  resulted  in  phasing  profiles,  presented  in  Figure  5  and 
Table  4,  that  are  slightly  front  loaded,  representing  the  increased 
requirements  and  design  costs  and  decreased  test  costs  typical  of  a  DoD- 
STD-2167A  development.  Six  funding  profiles  from  three  to  eight  years 
were  produced.  These  time  spans  were  selected  because  they  reflect  the 
range  of  current  CARD  DEMVAL  and  EMD  schedules  and  will  allow  cost 
analysts  the  flexibility  to  choose  a  profile  that  fits  their  specific  project 
estimate. 
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Figure  5.  Software  Spreading  Curves  -  Percent  by  Fiscal  Year 
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Figure  5  is  included  in  this  report  to  illustrate  curve  shapes  created  by  the 
annual  percentages  provided  in  Table  3. 


Table  4.  Time  Phasing  Factors 


FY  ^ 

FY? 

EU. 

FY4 

EYl 

FY_6 

ELL 

3  Years 

32% 

38% 

30% 

4  Years 

23% 

29% 

26% 

22% 

5  Years 

17% 

23% 

23% 

20% 

17% 

6  Years 

14% 

18% 

20% 

18% 

16% 

14% 

7  Years 

12% 

14% 

17% 

17% 

15% 

13% 

12% 

8  Years 

10% 

13% 

14% 

15% 

14% 

12% 

12% 

These  percentages  represent  effort  starting  on  1  October.  Fiscal  year 
percentages  should  be  adjusted  for  projects  that  start  later  in  the  fiscal 
year.  A  simple  proration  is  the  best  approach.  For  example: 


Year  1  Factor*  months  in  first  fiscal  year  ^2  months  =  partial  fiscal  year  factor 


As  an  example,  a  six  year  profile,  starting  mid-year,  would  require  that  the 
analyst  use  a  partial  year  factor  for  the  first  and  last  years  in  the  profile. 
Using  the  six  year  profile  factors  and  the  formula  alone,  the  analyst  would 
calculate: 
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14%*  — =  7% 
12 


Based  on  this  approach,  seven  percent  of  the  effort  would  be  placed  in  the 
Hrst  and  last  years  of  the  fiscal  year  profile. 


CONCLUSIONS/RECOMMENDATIONS 

The  equations  provided  in  this  report  can  be  used  in  any  automated 
spreadsheet  application.  All  that  is  required  is  total  software  development 
effort  and  total  required  months  to  produce  a  software  development 
profile.  The  analyst  should  rely  on  an  accepted  method  of  estimating  total 
effort  and  schedule  months  to  ensure  the  creation  of  an  achievable  cost 
estimate.  Successful  completion  of  a  given  software  development  project  is 
solely  dependent  on  the  optimum  effort  spread  over  the  optimum 
schedule.  Any  variations  almost  always  cause  performance  problems. 

These  equations  will  be  input  into  ARSEM/SPARC  to  be  used  as  our 
standard  software  spreading  approach. 
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CARD 

CER 

CDRL 

CSC 

CSU 

csa 

DID 

DoD 

FCA/PCA 


List  of  Acronyms 
Cost  Analysis  Requirements  Document 

Critical  Design  Review  -  at  this  review,  the  contractor  must 
present  his  build  to  design  for  customer  approval.  Typically 
conducted  for  each  configuration  item  when  detail  design  is 
essentially  complete.  Once  this  review  is  completed,  coding 
can  begin. 

Contract  Deliverable  Requirements  List  -  a  list  of  the  products, 
due  dates,  and  distribution  requirements  assigned  by  the 
customer  on  a  given  contract. 

Computer  Software  Component  -a  distinct  part  of  a  computer 
software  configuration  item  (CSCI).  CSCs  may  be  further 
decomposed  into  other  CSCs  and  CSUs.  CSCs  are  usually 
limited  to  approximately  5,000  SLOC  for  a  large  system. 

Computer  Software  Unit  -  An  element  specified  in  the  design 
of  a  CSC  that  is  separately  testable.  It  is  the  smallest  building 
block  or  component  of  a  software  system.  Usually  limited  to 
75  to  100  source  lines  of  code. 

Computer  Software  Configuration  Item  -  the  CSCI  is  the 
reportable  configuration  item,  with  DoD-STD-2167A 
documentation  requirements.  The  CSCI  typically  consists  of 
several  CSCs  with  an  optimum  size  of  50,000  SLCX^  or  less  in  a 
large  software  system. 

Data  Item  Description  -  the  DID  provides  the  report  format 
required  for  CDRLs. 

Department  of  Defense 

Functional  Configuration  Audit/Physical  Configuration  Audit  • 
FCA  is  a  formal  audit  to  validate  that  the  development  of  a 
configuration  item  has  been  completed  satisfactorily  and  that 
the  configuration  item  has  achieved  the  performance  and 
functional  characteristics  specified  in  the  functional  or 
allocated  configuration  identification.  PCA  is  a  technical 
examination  of  a  designated  configuration  item  to  verify  that 
the  configuration  item  "As  Built"  conforms  to  the  technical 
documentation  which  deftnes  the  configuration  item. 
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Firmware 

PQR 

RCM 

SASET 

SDR 

SDIO 

SlOC 

SPR 


List  of  Acronyms  (continued) 

The  combination  of  a  hardware  device  and  computer 
instructions  or  computer  data  that  reside  as  read-only 
software  on  the  hardware  device.  The  software  cannot  be 
readily  modified  under  program  control. 

Functional  Qualification  Review  -  the  objective  of  the  FQR  is  to 
verify  that  the  actual  performance  of  the  configuration  items 
of  the  system  as  determined  through  test  comply  with  Ihe 
requirements  speciHcation  and  to  identify  the  test 
reports/data  which  document  results  of  qualification  tests  of 
the  configuration  items. 

Rough-Order-of-Magnitude  -  a  cost  estimate  with  a  fidelity  of 
25  percent. 

Software  Architecture  Sizing  and  Estimating  Tool  -  a  software 
cost  estimating  model  designed  by  Martin  Marietta  for  the 
U.S.  Navy. 

System  Design  Review  -  conducted  as  the  final  review  prior  to 
the  submittal  of  the  DEMVAL  Phase  products  or  as  the  initial 
EMD  review  for  systems  not  requiring  a  formal  DEMVAL 
Phase.  Consists  of  a  review  of  the  System  Engineering 
Management  Activities,  results  of  trade  studies,  and  other 
updated  design  requirements. 

Strategic  Defense  Initiative  Office  -  PM  for  SDIO  programs. 

Source  Lines  of  Code  -  consist  of  all  executable  statements. 
Accounting  by  type:  format  statements,  data  declaration 
statements,  common  declarations,  dimensions,  deliverable  job 
control  language  statements  and  procedure  oriented  language 
statements. 

Software  Planning  Review  -  conducted  shortly  after  contract 
award  to  provide  the  customer  with  an  updated  Software 
Development  Plan. 
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SRR 


SSR 


IRR 


List  of  Acronyms  (continued) 

System  Requirements  Review  -  can  be  conducted  any  time, 
but  normally  conducted  after  accomplishment  of  functional 
analysis  and  preliminary  requirements  allocation  to 
determine  initial  direction  and  progress  of  the  contractor's 
System  Engineering  Management  effort  and  his  convergence 
upon  an  optimum  and  complete  configuration. 

Software  Specification  Review  -  usually  conducted  during 
system  concept  after  accomplishment  of  functional  analysis 
and  preliminary  requirements  allocation  to  configuration 
items. 

Test  Readiness  Review  -  conducted  for  each  CSCI  to  determine 
whether  the  software  test  procedures  are  complete  and  to 
assure  that  the  contractor  is  prepared  for  formal  CSCI  testing. 
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